Official Helium Community - hip-40-validator-denylist

## Info - Author(s): @BFGNeil - Trackpac.io, @Anthonyra, @ElonTusk | 5Gchipped - Start Date: 2021-09-27 - Category: Technical, Economic - Original HIP PR: https://github.com/helium/HIP/pull/284 - Tracking Issue: this - Status: In Discussion ## Rendered view https://github.com/helium/HIP/blob/master/0040-validator-denylist.md ## Summary While the situation with regards to Proof-of-Coverage gaming has improved and additional enhancements are intended, we need a backstop prevention mechanism that allows us to quickly allow the network to grow and deal with obvious gaming and spoofing situations as they materialize. This plan proposes that validators would maintain a denylist file of Hotspot addresses which are selected from a basic floor function, selecting the hotspots where earnings are abnormal, and then this is likey followed up with more metrics (see unresolved questions) This proposal has two consensus mechanisms: 1. how Hotspots are added or removed from the denylist 2. whether validators choose to adopt the community denylist

HIP draft – Validator Denylist by BFGNeil · Pull Request #284 · hel...

The first draft of hip 40? validator deny list.

HIP/0040-validator-denylist.md at master · helium/HIP

Helium Improvement Proposals. Contribute to helium/HIP development by creating an account on GitHub.

4

jamiedubs pinned a message to this channel. 09/29/2021 6:17 AM

Just as a note on this HIP, we're not talking about stopping all gaming, just the most high profile ones. This will not be a method for you to report hotspots in your area. The focus on those would be better served by altering the PoC process and ultimately would need another HIP. The selection so far is 18 hotspots, as can be seen here https://etl.dewi.org/public/question/54f5138b-b7ec-47c7-9da3-6a8c94ffe0eb - we are not saying these are all gaming, just that they should be investigated (edited)

1

@jerm How does one setup a Domain Name System-based blackhole list (DNSBL)? ... for us would it be P2PBL?? I briefly read the most informant and trustworthy source of information (wikipedia) and found myself lost in the sauce haha. I think it should be easy to access and use and remote to prevent "custom" alternations on validator side so it does sound like a better option in those regards

Would the deny list be an internal ledger curated within the scope of the validator and validator releases, or would it be something that validator operators would need to maintain on the system/infrastructure level?

deasydoesit

Would the deny list be an internal ledger curated within the scope of the validator and validator releases, or would it be something that validator operators would need to maintain on the system/infrastructure level?

There would be an entity published list included with new releases

07:43

Validators can choose to delete it/not include it and add to it

07:49

super majority of a list, and the contents would need to be achieved for it to take effect

Where would implementation of the list occur? At the validator level within the scope of libp2p? Ultimately I’m trying to understand what the implications are, if any, for validator operators.

When PoC transactions are submitted to the consensus group, if a super majority (66.6%) of consensus group members agree that a given Hotspot address is on the denylist, any witness receipts from that address will be marked as invalid with a reason of denylist

1

I added the notes from discord discussion to comments on the HIP. Also added some other personal comments/suggestions.

1

P2P stays connected (often they don't publish a listen address) so they can still submit, it just marks it invalid (edited)

EdB-charlietango

I added the notes from discord discussion to comments on the HIP. Also added some other personal comments/suggestions.

Calls in like 40 minutes :)

BFGNeil - Trackpac.io

Calls in like 40 minutes :)

If you want to jump on a call beforehand, I'm happy to talk through it. Most of it is pretty easy feedback. One point is worth considering...but maybe booting in light of urgency. (edited)

Anthonyra

@jerm How does one setup a Domain Name System-based blackhole list (DNSBL)? ... for us would it be P2PBL?? I briefly read the most informant and trustworthy source of information (wikipedia) and found myself lost in the sauce haha. I think it should be easy to access and use and remote to prevent "custom" alternations on validator side so it does sound like a better option in those regards

An entry on the list would be stored as a DNS record, perhaps a TXT resource, formatted in such a way that the full domain name of the entry would come from the address (b58 public key) of the hotspot being denied.

08:21

That’s the basics.

Ahhh that makes sense

The TXT response could contain the reason for denial.

When PoC transactions are submitted to the consensus group, if a super majority (66.6%) of consensus group members agree that a given Hotspot address is on the denylist, any witness receipts from that address will be marked as invalid with a reason of denylist

08:46

that can't work

08:46

at least not as described

ok sure

there are two possible mechanisms here: 1. we add bans to the chain, and they can work like that point describes (banlist would be a chain var) 2. the ban list needs to be the same on all of the validators currently in consensus

2

evan

there are two possible mechanisms here: 1. we add bans to the chain, and they can work like that point describes (banlist would be a chain var) 2. the ban list needs to be the same on all of the validators currently in consensus

does it need to the same one? Or just everyone need to agree that some need to be blocked?

recall that our consensus mechanism hides txns from other consensus members

10:07

so if we want to do denylist filtering, everyone has to agree

Can't the member talk to each other? and share there lists, and if someone doesn't have one, they can either add it to there list and say they have it, or say they don't have it, and the other member keeps those transactions, or drop them?

doesn't really work that way now, it would be a lot of new, speculative work

Gotcha, but it could be possible.

10:11

But the issue is that everyone needs the same list, and if someone has a hotspot that is denied, they will just stall the CG right?

I mean, you could work out a new system

10:23

but attempting to shoehorn something into the existing system, you will only filter spot X when spot X is on the list that everyone is using

10:23

if any validator in the cg accepts a txn into their proposal, it will be accepted by all

10:24

you could do post-hoc filtering, but that does risk halting the consensus group due to block disagreement

What about users who don’t games for big rewards just consistent low rewards

improving the network to catch the worst offenders should also catch lesser offenders

HeliumGoat

What about users who don’t games for big rewards just consistent low rewards

I agree

10:39

Measures taken been to be more accurate vs based in assumptions. This current method seems to me as more of a threat to the network than what it aims to resolve. It is the people's network and we should aim to keep that as fair as possible.

There need to be some form of AI code in place to detect location spoofing and gaming , as many people are probably still gaming that we don’t know about but just getting a small consistent reward , so they will go unnoticed ,

in fact I might agitate in favor of a watchlist rather than a denylist—scale down all of their earnings and see what tricks they come up with to make up for it

10:41

but that might require more engineering hours than are available to plug this hole (edited)

Oh and a big sorry to @JMF for stealing the 40th hip numbering (edited)

2

jpharris

but that might require more engineering hours than are available to plug this hole (edited)

To be clear from public talks that we've been having about this in #hip-discussion has already resulted in some changing tackticks of these hackers

This isn't meant to be for those people who simply put an address in discord claiming they have to be gaming. This system in my mind is to protect the blockchain from situations if left alone while an "actual" fix is being developed would lead to more damages than necessary. The current example is the account with Clever Smoke Raven (8HNT/day) but I'd hope this could also be further expanded to even help protect against Modesto / Port Huron situations and even Meerkat (we saw them mine 940 HNT per epoch)... the fixes took time and for every epoch (reward block) it lead to further damages to the network.. Returning to current since most people don't worry about the past unless they've been burnt by it personally. If the actual fix which there's one proposed for Clever Smoke Raven takes even a month to implement that account could have earned 3100 HNT and each month thereafter vs the 615 HNT as of right now (edited)

1

yeah, on board with the quicker solution

Now, this also requires the entire consensus group to agree to be 100% effective and I think that's achievable for examples like I gave above and less likely for a disgruntled "neighbor" hotspot trying to snuff out the competition (edited)

1

HIP will be updated soon to reflect but there are two options

10:52

https://discord.com/channels/404106811252408320/892761815795257424/892799868899295243

waveform pinned a message to this channel. 09/29/2021 11:03 AM

BFGNeil - Trackpac.io

HIP will be updated soon to reflect but there are two options

Clarification is probably needed as well between a "banlist" where they are preventing from earning HNT totally - does this mean they do not participate in PoC at all? So cannot witness, beacon or challenge or earn DCs. And there is a "denylist" where some earning options are denied such as "Witnessing" where in reality they are effectively classed similarly to "witness_too_close" to every other hotspot for PoC calculations. So cannot earn from witnessing but can challenge and issue beacons that others can witness, earn from those and also earn for data transfer. Or is the Deny for all PoC and they become "non interactive" for PoC, like a data only hotspot.

waveform

Clarification is probably needed as well between a "banlist" where they are preventing from earning HNT totally - does this mean they do not participate in PoC at all? So cannot witness, beacon or challenge or earn DCs. And there is a "denylist" where some earning options are denied such as "Witnessing" where in reality they are effectively classed similarly to "witness_too_close" to every other hotspot for PoC calculations. So cannot earn from witnessing but can challenge and issue beacons that others can witness, earn from those and also earn for data transfer. Or is the Deny for all PoC and they become "non interactive" for PoC, like a data only hotspot.

currently this is only describing witnessing being invalidated

11:11

challengee and beacon are both allowed, often what they have been doing is blocking inbound connections, and only submitting receipts to challengers, so this could be a sign the behaviour has been fixed

I can see great value in all rewards though since meerkat would be able to do what it did with this system

BFGNeil - Trackpac.io

currently this is only describing witnessing being invalidated

Yeah but people are talking of a "banlist" so wanted to make sure they understand there is a difference.

but right now a good majority of that list has no beacons, because this would show exactly where they are

1

At current this is more directed to the current gaming, and could be more focused than it should be.. it’s hard when you don’t know what the next “gaming” situation will consist of

BFGNeil - Trackpac.io

but right now a good majority of that list has no beacons, because this would show exactly where they are

So in effect turning them into DO-HS unless they come clean

fwiw the only dynamic system like you all are talking about that is possible is tossing out any txn that mentions a banned spot

waveform

So in effect turning them into DO-HS unless they come clean

yep

if we're monkeying with txn validity this list will need to be in the ledger

evan

fwiw the only dynamic system like you all are talking about that is possible is tossing out any txn that mentions a banned spot

OK so its an all or nothing situation

yeah

i wondered if there was a method for a user to anonymously restore service without having to appeal the ban and identify themselves, for example, returning to normal behaviour (edited)

BFGNeil - Trackpac.io

OK so its an all or nothing situation

I think this would line up better with a true stopgap however since we won’t know if beaconing is next or if dc rewards is next or some other txn like HTLC .. for that matter

1

@evan what is the approximate LOE on implementing something like this?

fairly low

Throwing a thought out....might a "non-coverage" mapping solution play into this in a useful way (similar sort of to the idea behind HIP-22 "anchor gateways" or "golden tabs", just reverse / distributed inference, I think). For example, perhaps hexes with reported hotspots that are flagged as "non-covered" can receive some kind of penalty similar to transmit scales (trust score / trust scale?), and in order to "restore" them the owners (or others, just owner has more incentive) would need to map them to some extent (edited)

11:27

Combine that with a localized copy of each denylist, and the way you improve the denylist score is by transferring more data (super super high level hamfisted example, hopefully the gist gets is generally getting across..)

11:29

That is, the denylist is only manipulated by parties that interact with the gateway in question. Trust of authenticity is degraded over time if a considerable number of attempts to transmit data in some defined radius are not successful. At that point even if you are legit the fact that you aren't effectively sending/receiving is problematic.

‍♂️

what was the thinking behind wanting to make the list a chain variable btw? forget who proposed that. that feels like the worst of the options as it is not easy for validators to opt in or out of

1

capcom

what was the thinking behind wanting to make the list a chain variable btw? forget who proposed that. that feels like the worst of the options as it is not easy for validators to opt in or out of

Not only that, but doesn't that make the list central, which is what the vast majority of the pushback is re "being on a list"?

1

I like the idea of there eventually being several listing orgs

1

I'm not familiar with the technicals of what I believe would be the witness list gossiping, but would a similar process work here?

jpharris

I like the idea of there eventually being several listing orgs

you mean like pseudo credit agencies?

11:42

@BFGNeil - Trackpac.io I think you had also mentioned a few things that could be implemented with some ML/AI if anyone in the community is versed enough. For example you had mentioned flagging suspect units that deviate a certain amount from the mean, or other suspicious behavior like earning more in 1D than the average makes in a week, etc. Those ML/AI solutions could perhaps be added to validators (perhaps even optionally) in such a way that the CG can either "learn" or "be taught" these patterns which it can then pick up in the data as aggregate in a way any given individual couldn't -- volumetrically and just from a standpoint of seeing patterns maybe a human wouldn't otherwise. Also appealing that it adheres to "code as law" rather than human trust systems. (edited)

🎈hnt.ChrisV.btc⚡

@BFGNeil - Trackpac.io I think you had also mentioned a few things that could be implemented with some ML/AI if anyone in the community is versed enough. For example you had mentioned flagging suspect units that deviate a certain amount from the mean, or other suspicious behavior like earning more in 1D than the average makes in a week, etc. Those ML/AI solutions could perhaps be added to validators (perhaps even optionally) in such a way that the CG can either "learn" or "be taught" these patterns which it can then pick up in the data as aggregate in a way any given individual couldn't -- volumetrically and just from a standpoint of seeing patterns maybe a human wouldn't otherwise. Also appealing that it adheres to "code as law" rather than human trust systems. (edited)

I think it's important we don't automate this deny too much, there are occasions , such as a stall, where hotspots earnt 150hnt in a day for example

true, however one offs like that I believe can generally be thrown out or ignored as outliers and likely wouldn't cross the algo's radar. But then again I am not the ML/AI expert here.

11:48

that is to say, I think that would be noise in the aggregate. but I could be wrong.

🎈hnt.ChrisV.btc⚡

true, however one offs like that I believe can generally be thrown out or ignored as outliers and likely wouldn't cross the algo's radar. But then again I am not the ML/AI expert here.

The basic floor has a etl question tho

11:48

https://etl.dewi.org/public/question/54f5138b-b7ec-47c7-9da3-6a8c94ffe0eb

It just feels personally like the whole gaming thing seems like a cat and mouse chase if there aren't at least some minimal "code enforcements" no pun intended

You should see the data when it's 7 days Vs 14, that brings up 300 odd hotspots

11:49

All of which I couldn't find more than 1-2 legit miners who beacon

11:49

So I think 14 days is right, only for the most extreme

BFGNeil - Trackpac.io

https://etl.dewi.org/public/question/54f5138b-b7ec-47c7-9da3-6a8c94ffe0eb

so what is the high level english version of what this is showing?

And then the PoC changes to limits of what a hotspot can reasonably limit Also go in

or filtering for, rather.

🎈hnt.ChrisV.btc⚡

so what is the high level english version of what this is showing?

Take the daily global AVG, X 14 (days) , anyone earning more than an average hotspot does in 2 weeks (edited)

TIMES 14 or over a 14 day rolling period

11:51

like a moving average

The main value of this proposal is that it gives the community a way to deal with issues that doesn’t require engineering resources to execute. Right now the problem with anything is that the level of expertise required to implement a solution is high. So I like having this backstop, even if it’s hugely flawed for several reasons

3

capcom

The main value of this proposal is that it gives the community a way to deal with issues that doesn’t require engineering resources to execute. Right now the problem with anything is that the level of expertise required to implement a solution is high. So I like having this backstop, even if it’s hugely flawed for several reasons

good point. very supportive of the "distributed" list as a primary axiom

this would be used for filtering and not "denying" poc right? maybe it's worth adding some definitions on a workflow directly into the HIP: step 1. identification step 2. analysis step 3. list generation / publish step 4. list combination / acceptance step 5. challengers censor poc witness receipts other important things: appeals, TTLs, implementation of list fetching (dns vs websites with json/yaml vs chain vars, etc.

11:54

i think this HIP is more about step 4, 5, and maybe things like appeals.

11:55

(and i'm making up steps here. just trying to get us out of the weeds)

2

🎈hnt.ChrisV.btc⚡

TIMES 14 or over a 14 day rolling period

I kind of invisioned the committee (for the first list of its kind, we want many list) would run this every 2 weeks to match the 14 days stats, one of my main conserns is that we drop those proposed 18 at the start 18 more will just pop up , but over time this would be less used (edited)

I guess my question would be what does the committee "do"?

Vote on each deny list entry